Modernly, the use of PCs (personal computers), including so-called laptop and notebook computers, is increasingly common and the computers themselves are ever more powerful and complex. A persistent problem is the unduly long elapsed time between the moment of power-on and the time when the PC has become ready for user stimulus and/or to initiate useful work.
Intel Corporation first defined EFI (Extensible Firmware Interface) as the programming interface exposed by firmware to O/S (operating system); former comparable firmwares were not sufficiently portable nor scalable to Intel's CPU (Central Processor Unit) IA64 architecture. A first implementation of the EFI interface became known as Tiano, which Intel Corporation offered under license via a web site. The UEFI Forum (Unified EFI Forum), a trade group, secured architectural control over EFI (and derivatives thereof) under a new name—UEFI, with a right to support and extend. The UEFI Forum documents and specifies the UEFI interface.
The PIWG (Platform Initialization Working Group) of the UEFI Forum provides a common internal framework for Silicon and platform drivers, so that a common understanding of the roles and methods used by Silicon and platform drivers is developed by implementers of UEFI firmware stacks together with the providers of the Silicon and platform drivers.
The UEFI and related standards provide richness, but fail to sufficiently address several significant specific areas of concern. The SCT (SecureCore Tiano™) System Overview published by Phoenix® Technologies Ltd. addresses a number of the problems.
One such problem with EFI/UEFI environments is the insufficiency (or complete lack) of a DLL (dynamic link library) facility for the use of developers of DXE (Driver Execution Environment) firmware. This is a runtime performance issue as well as a development issue.
The advantages of having a DLL capability available are well-known in the art and need not be further elaborated here. It is worth noting however that DLL facilities have not been generally available heretofore in EFI/UEFI environments and embodiments of the present invention shows how incorporation of such may advantageously be achieved. Previously developed solutions were not applicable because they depend either on a presence of an operating system environment or they require the control program to be adapted to support DLL capability. Embodiments of the present invention show how to achieve DLL capabilities without unduly restructuring the underlying foundation control program commonly termed “Foundation”.
A significant advantage of embodiments of the invention over previously developed solutions is a greatly reduced ROM (read-only memory) footprint (or size) of newly developed complete BIOS (Basic input-output system) sets of programs that exploit the invention.